Software Parameter Management

ABSTRACT

A method and apparatus is disclosed for allowing the updating and overriding of software parameters used by one or more software programs. The parameters are preferably in cache. When the system needs any such parameter, it first checks cache, then a preferably remotely located database, and then, preferably a flat file on the same computer as the cache. The checking is done in the foregoing order, and the parameter is used upon locating a current version of it. If the current version is obtained from anywhere other than the cache, it is put into cache.

TECHNICAL FIELD

This invention relates to computer software, and more specifically, toan improved method for managing one or more parameters that may be usedby one or more software applications.

BACKGROUND OF THE INVENTION

Software applications are ubiquitous in modern business. Such softwareapplications are often designed to be flexible so that business usersmay customize them to their own particular needs.

Often, the specific customization required varies throughout anorganization, and may vary over time even within one organization as theorganization uses the software. For example, software may be installedto provide one or more report formats, but a business entity may decidethat other formats are needed after some time. Error messages can befixed at the time of software installation, but as the organizationdiscovers other potential error conditions, the need may arise to beable to easily alter the error conditions. Generally, softwareapplications may require one or more parameters than they need to bealtered. The manner, frequency, and specifics of how the software willneed to be altered and customized is often unknown at the time ofinstallation.

Many times it is required to take the software application out ofservice in order to update these parameters. In situations where theparameters are hard coded into the software, this requirement mandatesthat the application be taken out of service. Moreover, if the softwareis running on a server with other applications, or is otherwiseintertwined with such other applications, they may have to be taken offline also. For mission critical software, this presents a problem for anorganization.

Even when parameters used by the software application are not hardcoded, if such parameters are placed in a flat file on an applicationserver where the software application is running, the softwareapplication may still need to be taken out of service in order to updatethe parameters.

Adding to the problem is that there is always a need to maximize thespeed at which such software applications execute. This is particularlytrue in a multiuser environment, where many users are accessing a singleapplication server. In such an environment, in order to maximize thespeed and thus minimize response time of the software application, it isbeneficial to have the needed parameters either hard coded into thesoftware or stored locally on a flat file in the computer's memory. Thisallows the fastest access to such parameters, and thus, most efficientexecution of the software. However, intertwining these parameters soclosely with the actual application also operates against the idea ofproviding flexibility so that such parameters can be altered as neededwithout taking the system out of service.

Thus, the need to provide flexibility operates against the requirementthat the parameters be available as quickly as possible to the softwareapplication. Specifically, the more intertwined the parameters needed bythe software are with the actual software code (e.g., hard coded), themore difficult it is to alter the parameters without taking down thesystem, and thus, the less flexible the software system is. Generallyhowever, the less intertwined the parameters are with the softwareapplication, the more easily they can be altered as needed.

In view of the foregoing competing requirements, there exists a need inthe art to optimize software concurrently both in terms of itsflexibility to permit alterations of parameters without taking thesystem out of service for an extended length of time, and also toprovide type intertwining of the parameters needed with the actualsoftware, in order to maximize speed at minimize response time. To date,there exists no known method of properly balancing these requirements.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows a conceptual diagram of an exemplary embodiment of thepresent invention, along with an exemplary set of steps for implementingone sample methodology in accordance with the invention; and

FIG. 2 depicts the components of the present invention in a networkenvironment.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

FIG. 1 depicts a conceptual diagram with an exemplary embodiment of thepresent invention. The arrangement of FIG. 1 includes a computer system100 that comprises at least an application server 107 and databaseserver 108. Not shown in FIG. 1 are optional local client PCs orterminals which may connect with the application server to execute oneor more applications. It is noted that the arrangement in FIG. 1 alsodoes not show a variety of other computers and terminals that may beconnected to the database server 108.

The arrangement of FIG. 1 is exemplary only, and is not intended tolimit the nearly infinite variety of computer networks that may beconfigured to implement the same functionality. Each of the databaseserver and application server may be distributed among plural computers.Moreover, the application and database server may be implemented on thesame or different computers.

In operation, an exemplary application represented by block 110 executeson the application server 107. When the application requires aparticular parameter, the application first checks cache memory 103 ifthe parameter is found in cache memory 103, and if the cache is deemedcurrent enough to be useful, the application 110 simply utilizes theparameter from cache.

Whether or not a parameter in cache is deemed current enough may vary byparameter. Specifically, the system designed and typically knows inadvance approximately how often the cache memory should be updated witha new value. The value that is to replace the cache value comes fromanother source, for example, database 102. Thus, if the desiredparameter is either not found in cache memory 103, or the applicationdetermines that, although the parameter is found in cache memory 103, ithas timed out, the next step described below is executed.

If either the parameter has timed out in cache, or if it is not presentat all in cache, then an additional source such as database 102 (orother file) is checked for a current version of the necessary parameter.Database 102 is preferably, but not necessarily, a database and is alsopreferably implemented on a separate database server as shown in FIG. 1.By implementing database 102 on a separate server 108, new data can bepopulated into the database without taking down the system, and thisdata will find its way into the cache as a result of the methodologydescribed herein. Moreover, if the database is not operable, the systemcan simply move to the next step shown in FIG. 1, just the same as if itdid not find the data in database 102.

If the required parameter is located in database 102, it is written tocache memory 103 and also utilized by application 1 10. However, if theparameter is not found in database 102, the flat file 104 is thenchecked, and the data presumably located. In all events, however, thevalue of the parameter is retrieved at block 105 and placed into cachememory 103 for subsequent use.

FIG. 2 depicts and additional embodiment of the present invention inwhich the application server includes plural terminals 205-207, and twodatabase servers 209 and 108. In such a case, a parameter in cachememory may also specify, in the cache, which of the database servers the209 or 108 to use for the updated parameter. In this manner, if theneeded parameter is not in the cache at all, the next step would be tocheck the database servers 108 and/or 109. These two servers mayrepresent one live and one backup, or, they may represent multipleservers for storing a large amount of data, such that the database isimplemented between the two of them.

Alternatively, if the parameter is in cache 103 but has time out, thecache version could include a pointer to the specific database server tocheck, thereby eliminating the need to check plural servers.

Preferably, the system designer will ascertain in advance which ofnumerous software parameters change often enough to use the database orother file 102, and which do not change so frequently. Thus, forparameters like passwords, for example, which users tend to maintainlong term, the flat file or hard coding can be used. For parameters suchas a customer balance in an account, the database server 108 anddatabase 102 can be used as the source of these. Thus, all parameterswill gradually be moved into cache as the software application(s) thatneed them are run on the application server 107, and the cache will bykept up to date using the timeout features described above.

In one embodiment, all parameters that may be used by the softwareapplication and which vary are divided into groups in advance of use.Parameters expected to be updated more frequently than the predeterminedthreshold are placed into the database 102, whereas, parameters expectedto be updated less frequently than the predetermined threshold areplaced into the flat file. In this manner, once the application(s) areup and running, the parameters gradually migrate into cache, and theones that need to be updated more frequently than the the threshold canbe changed while the software applications using them are “live”.

Notably, parameters in the flat file 104 can also be put into thedatabase file 102. Such a situation will arise when a parameter waspreviously selected for the flat file, but the developer wishes tooverride the value. Rather than have to take the application out ofservice to update the flat file, the parameter can just be put into thedatabase 102. Due to the order in which the sources for the parameterare checked, as described above, the system will continue to operate,but the database file will trump the flat file because it is checkedfirst.

The above technique can also be used to allow a parameter in the flatfile, and which can thus be accessed very quickly by the softwareapplication, to be altered without having to take down a softwareapplication using those parameters. Specifically, consider the casewhere the desired parameter is one that does not vary all that often, soit is placed in flat file 104. If a time comes that such a parametermust be changed, the system can then change it by placing the parameterin database 102, even though it is not normally kept there.

Due to the order in which the software application checks for sources ofthe parameter (described above), the software application will continueoperating, however, it will do so using the new value of the parameterin database 102. Then, if it is desired to permit even faster access byplacing the parameter in flat file 104, at least two methodologies canbe utilized. First, the flat filed can be updated with the new value ata time when the application is not used, or at least less critical(e.g.; overnight). Alternatively, the software itself can be programmed,and the parameter in database 102 tagged, so that the software itself isinstructed to place the new parameter into the flat file after it isfirst read into cache from the database 102.

The system may also keep track of the number of times a parameter isreplaced with information from the database. In this manner, if aparameter was designated by the developer for the flat file, but thesystem detects that it is changing too often, it can alert the developerto reallocate such parameter to the database file 102.

While the above describes the preferred embodiment of the presentinvention, various other modifications can be implemented withoutdeparting the spirit and scope of the invention.

1. A method comprising: executing software as a sequence of steps; whena step occurs that requires at least one of a set of predeterminedparameters, checking cache memory for at least one valid value of saidat least one predetermined parameter; if said at least one valid valueof said predetermined parameter is in cache, obtaining said at least onepredetermined parameter from cache; if said at least on predeterminedparameter is not contained in cache, checking a database for said atleast one predetermined parameter; if said at least one predeterminedparameter exists in said database, moving it into cache, and using it insaid step; if said at least one predetermined parameter does not existin said database, obtaining said at least one predetermined parameterfrom a third file other than cache and other than said database, andmoving said at least one predetermined parameter into cache; and usingsaid at least one predetermined parameter in said step regardless offrom where it was obtained.
 2. The method of claim 1 wherein said thirdfile and said cache reside on the same server.
 3. The method of claim 2wherein said database resides on a different server from said third fileand said cache.
 4. The method of claim 1 wherein said at least one validvalue is deemed present in cache if said predetermined parameter islocated in cache and if an expiration time associated with saidpredetermined parameter has not lapsed.
 5. The method of claim 4 whereinthe expiration time associated with at least one of said predeterminedparameters is different from the expiration time associated with atleast one other of said predetermined parameters.
 6. The method of claim5 wherein parameters that vary more often than a predetermined frequencyare not stored in said third file.
 7. The method of claim 5 whereinparameters that vary more often than a predetermined frequency arestored in said database.
 8. A method comprising executing a softwareapplication on an application server, using memory on said applicationserver as cache memory, if a valid value of at least one parameterneeded for said application can be found in said cache, using said validvalue in said application, if not, first checking a remote file on adifferent server and then a local file on said application server for avalid value of said parameter, and if said valid value of said parameteris found in either said remote file or said local file, moving it intocache.
 9. The method of claim 8 wherein if said valid value is found insaid remote file, not checking said local file.
 10. The method of claim9 wherein parameters in said local file vary less frequently thanparameters in said remote file.
 11. The method of claim 8 wherein saidremote file is a database.
 12. The method of claim 9 wherein saidparameters are in both said local file and said remote file.
 13. Themethod of claim 9 wherein said parameters are in either said remote fileor said local file but not both.
 14. A method of using cache on a firstcomputer, said method comprising populating said cache with parametersfor use by a software application, said populating comprising obtainingsome of said parameters from a first file located on said firstcomputer, and others of said parameters from a second file located on asecond computer connected over a network to said first computer, whereinat least some parameters are located both in said first file and in saidsecond file, and wherein said step of obtaining comprises executing, byan application which requires use of at least one of any of saidparameters, steps that first check said second file, and upon findingone of any of said parameters, places it into cache and uses it in saidapplication, and upon not finding said one of any of said parameters,checks said first file, and upon finding said one of any of saidparameters in said first file, populates said cache with said one ofsaid parameters.
 15. The method of claim 14 wherein upon finding one ofany said parameters in said second file, said steps do not check saidfirst file for said one of any of said parameters.
 16. The method ofclaim 15 wherein at least one of said parameters in said second file isplaced there after being placed in said first file and after it isdetermined that said at least one of said parameters is required to varyat more than a predetermined frequency.
 17. A computer system comprisinga first computer, a second computer, and a network connecting said firstand second computers, the first computer having a first file, the secondcomputer having a second file, said computer system further comprisingcache memory, and a processor programmed to execute an application thatlocates a parameter for use by first checking cache, then the secondfile, then the first, using the parameter when it is first located fromany source, and loading it into cache at substantially the time of useif its not already in cache.
 18. The computer system of claim 17 whereinthe first computer is an application file and the second computer is adatabase server.
 19. A computer system comprising: a plurality ofterminals connected to an applications server, the terminals beingconfigured to execute concurrently one or more applications running onthe applications server, the applications requiring a plurality ofparameters, at least one file server; at least one data networkconfigured to facilitate communications between said file server andsaid applications server wherein upon an application requiring use of aparameter, said application first checks a first memory source that doesnot require communications over said data network, second checks asecond memory source that does require communications over said datanetwork, and third checks a third memory source that does not requirecommunications over said data network, wherein said first and thirdmemory sources may provide data more quickly than said second datasource, and wherein, if said parameter is deemed present and current insaid second or third memory sources by not in said first, it is movedinto said first memory source.
 20. The computer system of claim 19wherein said first memory source is cache, said second memory source isa database, and said third memory source is a flat file.
 21. A systemcomprising computer storage containing a plurality of parameters for useby an application, at least one said parameter including an associatedindicator of an additional source for a current version of saidparameter, and a means for obtaining said parameter from said computerstorage if a current version of said parameter exists therein, and, ifsaid current version of said parameter does not exist therein, forchecking first a potential second source and then said additional sourceif said parameter does not include said associated indicator, and ifsaid parameter includes said associated indicator but if said currentversion of said parameter does not exist therein, checking saidadditional source without first checking said potential second source.22. The system of claim 21 wherein said computer storage is cache andsaid additional source is a file located on a server that also includesthe cache.
 23. The system of claim 22 wherein said second source is acomputer other than the computer that includes the computer storage. 24.A method comprising placing a software parameter in a first file thatcan be accessed by a software application at a first speed, determiningthat said parameter needs to be replaced with an updated version,placing the updated version in a second file that can be accessed at asecond and slower speed, using the updated version in a softwareapplication, and then placing the updated version thereafter in saidfirst file to replace the software parameter.
 25. The method of claim 24wherein said first file is a flat file.
 26. The method of claim 24wherein said updated version is moved into a cache memory after beingplaced in said first file.
 27. The method of claim 26 wherein said firstfile and said cache memory reside on a first computer and wherein saidsecond file resides on a second computer.
 28. The method of claim 27wherein said second file is a database server.
 29. A computer systemcomprising cache memory, a first file, and a second file, the computersystem comprising software that requires at least one parameter tooperate, and upon reaching a point in operation wherein said parameteris needed, checks for said parameter first a cache memory on a firstcomputer, then a second file on a second computer, and then a first fileon said first computer, and obtains and uses said parameter fromwhichever source is first determined to include a valid value of saidparameter, and wherein if said valid value of said parameter utilized innot obtained from cache, moving said valid value into cache.
 30. Thecomputer system of claim 30 wherein at least one of said files is adatabase file.